Software instrumentation generally includes software entities used for collecting, storing and retrieving performance metrics of a computer system.
These software entities typically include writer entities for collecting the performance information and storing that information in a designated area of main memory, called a repository. The repository preferably holds the performance information for retrieval by reader entities, which may include application programs executing on the computer.
Namespace services impose a uniform structure on the information stored in repositories. A namespace is a collection of information managed by an operating system of the computer and a namespace service, or registry, is the entity that stores and organizes that information. The registry generally provides an application programmning interface (API), which is a mechanism for an application program to obtain services from the operating system. APIs typically include a collection of system calls to the operating system requesting, for example, establishment of network connections on behalf of an application. Specifically, the application may, via system calls to the registry API, create, modify, request, add and delete information in the registry.
The performance information collected at the registry typically includes metrics relating to components of the computer system, such as a central processor unit (CPU), main memory, the operating system and input/output (I/O) system. Examples of the collected information include loading metrics of the CPU and bandwidth parameters of the memory, along with timing latencies for execution of a particular request involving the I/O system, e.g., how long it takes to complete the (entire or portions of the) request.
By collecting and retrieving performance information, the software instrumentation provides access to the internal state and behavior, i.e., "views", of the operating system and application software executing on the computer. Operating systems are complex pieces of software configured to, e.g., handle asynchronous events within a computer (such as interrupts from I/O devices), provide interprocess communication capabilities and implement complex network protocols. Operating systems also control execution of application programs; instances of those programs in execution are called processes.
Knowledge of the internal characteristics of an operating system and application processes is useful for debugging, optimization and design verification of a computer. The internal views provided by software instrumentation fall into two general categories: (i) tracing, which provides a view into the behavior of a software program by recording the time and details of its state at interesting points in a running system, and (ii) statistics, which record when and how resources, such as device drivers of the operating system, are used.
Tracing is a form of interprocess communication that enables a process to observe the execution of another process; a trace, therefore, consists of a display that chronicles the actions and results of that program execution. Specifically, the trace provides a detailed record of the program's execution path by, e.g., taking an application program and placing it under observation by a special routine that monitors the progress of the program.
Several known operating systems have capabilities to acquire and register performance information. The UNIX.RTM. operating system uses various software entities, known as KMEM readers, to access performance information stored in data structures within privileged memory for purposes of, e.g., displaying that information. Here, the performance information is collected solely within the operating system and registration is effected with a symbol table of a compiler.
Registration of information for the UNIX operating system is done implicitly by the compiler because symbols for various pieces of the information are inserted in the symbol table. Applications attempting to access the information must know precisely which symbols are meaningful, i.e., which symbols are associated with particular types of information; the applications use the KMEM readers to access that information from memory for display on a computer screen.
Another known registration mechanism allows applications to access performance information without knowledge of the various types of collected information. That is, applications can query the operating system as to the existence and types of collected information. As with the previously-described mechanism, the performance information is collected and stored solely within the operating system and, as a result, the registration mechanism is typically only available to the operating system.
Moreover, the information is registered in the namespace according to a "flat" list of entries in the registry. This registration namespace structure obviates grouping of information in a logical organization since only individual pieces of information can be identified. Not surprisingly, the list of registered entities is typically quite long and, furthermore, unwieldy and expensive to manipulate. For example, accessing specific entries of the list requires searching the entire list, typically with the use of a hashing algorithm.
Therefore, it is among the objects of the invention to provide a registration architecture that efficiently organizes performance information collected by an operating system and application program.
Another object of the present invention is to provide a registration architecture that facilitates extension of the types of performance information collected by operating systems and applications.